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TECHNIQUE FOR EFFECTIVELY CAPTURING 
AND PROCESSING EVENT DATA 

This application claims priority of U.S. Provisional Application no. 
60/244,086 filed on October 27, 2000 under 37 U.S.C. § 1 19(e). 

Field of the Invention 

The invention relates to a data collection and processing technique, and more 
particularly to a technique for capturing and processing data concerning events such as 
those occurring during a communication, e.g., information assistance calls. 

5 

Background of the Invention 

It is a common experience to call a telephone operator for information assistance. 
In a typical information assistance call, a customer identifies to the operator the name and 
address of a party whose telephone number is desired. In response, the operator locates 

10 the desired destination number using, e.g, a computer database. The destination number 
is then provided to the customer, e.g., by a computerized voice response unit (VRU) 
which provides a synthesized voicing of the number, and the customer is afforded an 
option to be connected to the destination number without the need of first terminating the 
information assistance call. 

15 In the event that the connection to the destination number is made for the 

customer, the operator may stay on the line as a conferenced party so as to provide further 
assistance. Alternatively, in a "StarBack" service which is described in U.S. Patent No. 
5,797,092 issued August 18, 1998 to Cox et al., the connection may be continually 
monitored for a predetermined DTMF signal, such as that obtained by pressing "*" 

20 button, issued by the customer. If such a signal is detected, the customer is transferred 
back to an operator, who can then provide further assistance. 

Additional services may be provided in an information assistance call. For 
example, upon request, an operator may also provide a customer with information on 



41698.1117 



regional restaurants, movie listings, and directions to various places, etc. Thus, during an 
information assistance call, multiple events may occur which include, e.g., a destination 
number connection event, StarBack event, restaurant search event, movie inquiry event, 
directions inquiry event, etc. 
5 In prior art, for marketing analysis and other reasons, statistics concerning 

information assistance calls is compiled based on call detail records (CDRs) generated by 
a switch system at a call center. However, the information provided by the CDRs is 
limited to a tally of the calls handled by the operators at the center, and the length of each 
call. The compilation of the statistics is also based on data concerning any of the 

10 aforementioned events which occur during a call. The collection of such data relies on 
the cooperation of all of the operators who are required to manually record the events 
during each call. However, the resulting statistics is subject to error as the manual 
recording may be based on the operators' recollection of the events during a call and is 
thus unreliable, especially when the operators are busy handling calls having many events 

15 therein. 

Thus, it is desirable to have a system and method for effectively capturing and 
processing data concerning the call events to yield accurate statistics thereof. 

Summary of the Invention 

20 The invention overcomes the prior art limitations by using, among others, an 

event monitor server to collect and process data concerning events. We have recognized 
that the application of the invention is not limited to events which occur during 
communication calls. Rather, the invention generally applies to any events or 
occurrences which may be described and/or identified by data, and which may occur 

25 during transactions, inquiries, transmissions, etc. In addition, events may be generated 
based upon other events. 
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By way of example, but not limitation, the event monitor in accordance with the 
invention is used in a call center to collect and process data concerning events which 
occur during communication calls. The event monitor server is connected to clients, e.g., 
the aforementioned VRU and switch system, in the call center. Each client automatically 
5 generates an event record when it is used in handling the call, thereby realizing an event 
whose description is included in the event record. In addition, the event records 
concerning the events realized in the same call each include an identifier identifying the 
call. 

After collecting the event records from the clients, the event monitor server 
10 transmits the data in the records through a communications network to a remote 

computer for manipulation and analysis of the data, thereby yielding accurate statistics 
concerning the events. To effectively utilize the limited bandwidth of the 
communications network, in accordance with an aspect of the invention, the event 
monitor server performs data compression on the event data before its transmission. In 
15 addition, in response to a substantial transmission latency, the server may control the rate 
at which the event data is transmitted by implementing a data throttling scheme. In the 
event of a loss of a connection to the remote computer, the server causes the event data to 
be stored in a memory, e.g., a cache, until the connection is reestablished. At such time, 
transmission of the event data from the cache resumes. Moreover, priority may be 
20 accorded to selected event records concerning, e.g., a particular event type. Accordingly, 
the data in the event records having a relatively high priority status is transmitted ahead of 
the data in those having a relatively low priority status. Further, the server may filter out 
unwanted event records before their transmission based on selected data values in the 
records. 

25 In accordance with another aspect of the invention, the functions of the event 

monitor server, e.g., the aforementioned data compression and throttling functions, are 
realized based on specified parameters in a configuration file. Advantageously, these 
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functions can be flexibly modified and implemented by easily changing the parameters in 
the file. 

In accordance with yet another aspect of the invention, after the remote computer 
receives the event records from the event monitor server, data in the received records is 
5 inserted into a database. Additional events are identified based on selected data being 
inserted into the database. Event records representing the additional events are then 
generated. 

In accordance with still yet another aspect of the invention, in compiling statistics 
concerning at least one communication call, selected ones of the received records are 
10 associated with the communication call based, e.g., on an identifier in the selected records 
which identifies the communication call Statistics concerning the communication call is 
then generated based on data in the selected records. 

Brief Description of the Drawing 

15 Further objects, features and advantages of the invention will become apparent 

from the following detailed description taken in conjunction with the accompanying 

drawing showing an illustrative embodiment of the invention, in which: 

Fig. 1 is a block diagram of a call center in accordance with the invention which 

receives information assistance calls; 
20 Fig. 2 illustrates a record concerning an event which occurred during an 

information assistance call; 

Fig. 3 illustrates an arrangement wherein an event monitor server collects event 

records in the call center of Fig. 1 and transmits the records to a remote computer in 

accordance with the invention; 
25 Fig. 4 is a flow chart depicting a process whereby the event monitor server 

collects and transmits the event records to the remote computer; 



-4- 



41698.1117 



Fig. 5 is a flow chart depicting a routine for auto-generating event records based 
on other event records in accordance with the invention; 

Fig. 6 illustrates a first table for summarizing data from event records in 
accordance with the invention; 
5 Fig. 7 illustrates a second table for summarizing data from event records in 

accordance with the invention; 

Fig. 8 illustrates a table which is used to help develop summarization data in the 
table of Fig. 7; and 

Fig. 9 is a flow chart depicting a routine for developing the summarization data in 
10 the table of Fig. 7. 



Detailed Description 

The invention is directed to collecting and processing data concerning events. In 
general, events are occurrences which may be described and/or identified by data, and 

15 which may occur during communication calls, transactions, inquiries, transmissions, etc. 
In addition, events may be generated based upon other events. 

In this illustrative embodiment, the events in question occur during 
communication calls, e.g., information assistance calls. Fig. 1 illustrates call center 10 
embodying the principles of the invention which receives information assistance calls. 

20 As shown in Fig. 1, call center 10 includes switch 14 having Tl spans 12 for connection 
to voice response unit (VRU) 30, channel bank 16 and customer networks. Channel bank 
16 is used to couple multiple operator telephones 18 to switch 14. The operators in center 
10 are further equipped with operator terminals 20, each of which includes a video 
display unit and a keyboard with associated dialing pad. Operator terminals 20 are 

25 coupled to terminal server 22, which in turn is connected over data network 24 to 

database server 26. Event monitor server 43 in accordance with the invention, switch 
host computer 28 and VRU 30 are also connected to data network 24. By way of 
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example, data network 24 includes a local area network (LAN) supplemented by a 
number of point-to-point serial data links. 

Call center 10 may receive an incoming information assistance call from one of 
the customer networks through a carrier switching center in the network. It also places 
5 outgoing calls through one of the customer networks which may be different than that 
used for the incoming call. 

Switch 14 is conventional which includes digital signal processing circuitry which 
provides the requisite conference capability and dual tone multi-frequency (DTMF) and 
multi frequency (MF) tone generation/detection capabilities. In this illustrative 
10 embodiment, switch 14 supports digital Tl connectivity. The operation of switch 14 is 
governed by instructions stored in switch host computer 28. 

Each incoming information assistance call from a customer is received by switch 
14 in center 10 which connects it to an available operator's telephone. If no operator is 
available when a call is received, the call is queued in a conventional manner until an 
1 5 operator becomes available. 

Terminal server 22 serves as an interface between serial devices, such as operator 
terminals 20 and data network 24, allowing the terminals to login as devices on the 
network. Operators may utilize database server 26 to provide information assistance 
including searching for a customer's desired party and determining the appropriate 
20 destination number of the party. The destination number is then provided to the customer 
via VRU 30 which provides a synthesized voicing of the number, and the customer is 
afforded an option to be connected to the destination number without the need of first 
terminating the information assistance call. 

VRU 30 is used to play the constant repeated parts of an operator's speech, 
25 namely, the various greetings and signoffs (or closings). VRU 30 is connected via data 
network 24 to switch host computer 28 and via one or more Tl spans to switch 14. At 
appropriate stages in a call progression, switch host computer 28 initiates a voice path 
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connection between VRU 30 and switch 14 such that the caller, or the caller and the 
operator, are able to hear whatever pre-recorded speech is played on that connection by 
VRU 30. Computer 28 then instructs VRU 30, via data network 24, what type of 
message to play, and passes data parameters that enable VRU 30 to locate the message 
5 appropriate to the call state. 

Let's assume that during an information assistance call a customer selects the 
option to be connected to the destination number located by an operator. In accordance 
with a well known "StarBack" service, switch 14 continually monitors such a connection 
for a predetermined DTMF signal, such as that obtained by pressing "*" button, issued by 

10 the customer. If such a signal is detected, the customer is transferred back to an operator, 
who can then provide further assistance. If the connection to the destination number 
results in ringing without answering, switch 14 instructs VRU 30 to present, in 
synthesized voice, a menu of options to the customer including, e.g., leaving a message 
for the non-answering party, continually calling the non-answering party every N minutes, 

15 paging the non-answering party, etc. 

An operator may also utilize database server 26 to provide additional assistance 
including searching by type of goods/services and/or geographic region, thereby 
providing the customer with information on regional restaurants, movie listings, and 
directions to various places, etc. Thus, during an information assistance call, multiple 

20 events may occur which include, e.g., a destination number connection event, StarBack 
event, restaurant search event, movie inquiry event, directions inquiry event, etc. 
In accordance with the invention, event monitor server 43 is used to capture event data 
generated by each client in center 10 (e.g., switch 14 and switch host computer 28, 
database server 26, or VRU 30 being one such client) when the client realizes the 

25 corresponding event. Thus, for example, when a customer calls for information 

assistance, and an operator is unavailable, the call is placed in queue by switch 14. At the 
same time, switch host computer 28 generates a first event record concerning the queuing 
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event. When the call is ultimately connected to the operator by switch 14, computer 28 
then generates a second event record concerning the operator connection event. If the 
customer asks the operator to search for restaurants in a particular area, given the 
customer's preferences, the operator utilizes database server 26 to locate such restaurants. 
5 Database server 26 then generates a third event record concerning the restaurant search 
event. Further, if the customer asks to be connected to the destination number of one of 
the located restaurants, the operator (a) determines the destination number using database 
server 26, which then generates a fourth event record concerning the determination of the 
destination number, and (b) initiating a call to the destination number through database 

10 server 26, which then generates a fifth event record concerning the call initiation. 

Accordingly, switch 14 connects the current information assistance call to the destination 
number, and computer 28 generates a sixth event record concerning the connection. If the 
connection results in ringing with no answer, VRU 30 presents the aforementioned menu 
options for selection by the customer, and generates a seventh event record concerning 

15 the menu presentation. If for any reason the customer utilizes the StarBack service to be 
re-connected to an operator, switch 14 generates an eighth event record concerning the 
StarBack event. As one can appreciate that as the information assistance call goes on, 
more and more events may occur and thus event records are generated during the call. 
Fig. 2 illustrates one such event record, denoted 200, generated by a client during an 

20 information assistance call. As shown in Fig. 2, event records 200 includes multiple 

fields describing an event. Specifically, EVENT JVIONITORJD field 203 identifies the 
event and is used to synchronize communications between the client generating the event 
record and event monitor server 43, and between server 43 and a daemon process 
running on a remote computer described below. For example, the value in field 203 

25 "nyc0tek99:20000829 1 55959487:3300" is used to identify record 200 in acknowledging 
receipt thereof in such communications. Field 205 identifies a table, e.g., Basic_E vents 
table in this instance, which is maintained in the remote computer and into which selected 
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data in record 200 is integrated. SUBSCRIBERMDN field 207 identifies the telephone 
number of the customer who made the information assistance call. INJSPAN field 209 
identifies the Tl span transporting the incoming communication of the information 
assistance call. In this illustrative embodiment, each event is identified by an event type 
5 within an event class. EVENT_CLASS_ID field 21 1 specifies one of the event classes to 
which the instant event belongs. For example, the value "20" in field 21 1 in this instance 
corresponds to a CALL PROCESSING class. Other values for field 21 1 may correspond 
to, e.g., SEARCHES, VALUE ADDED SERVICE and LOCAL SERVICES classes. 
EVENT_TYPE_ID field 247 specifies one of the event types within the class identified 

10 by the value in field 211. For example, the value "23" in field 247 in this instance 

corresponds to a StarBack event within the CALL PROCESSING class. Similarly, other 
values for field 247 correspond to different types of event in an identified class. 
CDR_CALL_SEQ_NMBR field 213 contains a sequence number identifying the 
information assistance call in question. It should be pointed out that event records 

15 concerning different events occurring in the same call share the same value in field 213. 
To this end, when the information assistance call is initially received by switch 14, switch 
host computer 28 assigns a sequence number identifying the call. It then generates and 
transmits a network message to each client connected to network 24, informing the client 
of use of the same sequence number to identify the current call. 

20 Fields 217, 219, 223, 227 and 229 are reserved in this instance, which may be 

used to include more specific information concerning the event. IN_CHANNEL field 
221 identifies the channel (within the Tl span identified by field 209 previously 
described) which the incoming communication of the information assistance call 
traverses. OUT_CHANNEL field 225 identifies the channel (within the Tl span 

25 identified by field 249 described below) which the outgoing communication of the 

information assistance call traverses. MARKETJD field 231 identifies the carrier switch 
through which the information assistance call comes in. For example, the value "184" in 
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field 23 1 identifies the carrier switch located at Boise, Idaho in this instance. Thus, the 
information in field 23 1 also helps identify the geographic market using the information 
assistance service. Site_ID field 233 identifies the site of the call center receiving the 
information assistance call. LCA_ID field 235 identifies any table containing number 
5 plan areas (NPAs), also known as "area codes," which pertain to the local calling area 
from which the information assistance call comes. CARRIERJD field 237 identifies the 
carrier used to connect the call. For example, the value "79" in field 237 identifies 
AT&T Corp. as the carrier in this instance. DATA_SOURCE_ID field 239 identifies the 
client which generates record 200. EVENT_START_TIME field 241 indicates the start 

10 time of the event in question. It should be noted that the value in field 241 corresponds to 
a UNIX "epoch" time, i.e., the number of seconds elapsed from January 1, 1970. It 
should also be noted that had the event in question, i.e., the StarBack event, not been 
instantaneous, an EVENTJENDJTIME field corresponding thereto would also be 
included in record 200 to account for the duration of the event. OPERATORJLOGINJD 

15 field 243 identifies the operator handling the event. Field 245 alternatively states the start 
time of the event as an offset from the Greenwich Mean Time (GMT), which offset is "- 
14400" seconds in this instance. Field 247 is described previously. OUT_SPAN field 
249 identifies the Tl span transporting the outgoing communication of the information 
assistance call. 

20 In this instance, each event record is further formatted by the client generating the 

record in packet form by adding a header to the record. Such a header includes the 
destination address of event monitor server 43 to which the packet is routed. It also 
includes, e.g., an indicator indicating the amount of data in the record. 
In a conventional manner, data network 24 routes each event record packet to server 43 

25 based on the destination address therein. Referring to Figs. 3 and 4, server 43 receives 
the event record packet through data network interface 307. Processor 3 1 1 extracts the 
event record content from the received packet, as indicated at step 403 in Fig. 4. 
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Processor 3 1 1 at step 407 determines whether the amount of data in the event record 
content corresponds to the value of the data-amount indicator in the header. If the 
amount of the data corresponds to the indicator value, processor 3 1 1 assumes that the 
event record content is complete, and thus transmits an acknowledgment of receipt of the 
5 record identified by the EVENTMONITORID value in the record, as indicated at step 
410. The subject routine then proceeds to step 413 described below. Otherwise, if the 
amount of data does not correspond to the indicator value, processor 3 1 1 assumes that the 
event record content is incomplete, and thus transmits a negative acknowledgment of 
receipt of the record, requesting retransmission of the event record packet, as indicated at 
10 step 415. 

Event monitor server 43 further processes the data in the received event record to 
achieve effective communication of the data through a communication network, e.g., 
wide area network (WAN) 325, to remote computer 334 for manipulation and analysis of 
the data. To that end, processor 3 1 1 at step 413 performs compression of the event data 

15 before its transmission. For example, it translates selected terms in an event record which 
are frequently used to representations thereof which require less bandwidth to transmit. 
Such terms may include field names such as "SITEJD," "EVENT_CLASS," etc. and 
table names such as "BASIC_EVENT" which frequently appear in an event record. A 
translation table containing the selected terms and the corresponding representations is 

20 stored in memory 313. In this illustrative embodiment, the representations used are 
numeric representations, e.g., 3-digit numerals. Memory 313 here generically includes 
disks, caches, and volatile and nonvolatile memories. The translation table is made part 
of configuration file 3 1 5 cached in memory 313. Configuration file 3 1 5 is further 
described below, it suffices to know for now that configuration file 315 contains 

25 information based on which event monitor server 43 is configured and operates. 

Thus, in accordance with the aforementioned translation table, server 43 translates such 
terms as "BASIC_EVENT," "SITEJD," "EVENT_CLASS," ... in the event record to the 
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corresponding 3 -digit numerals to condense or compress the event data to be transmitted. 
Before transmission of the compressed event data, which is packetized pursuant to a 
predetermined protocol, processor 311 determines whether a FLAG is set to one, as 
indicated at step 414. This FLAG is initially set to zero and used to indicate whether the 
5 transmission of the event data packet to remote computer 334 should be controlled in 
accordance with a data throttling scheme described below. If FLAG = 1, the subject 
routine proceeds to step 425 described below. Otherwise, if Flag = 0, processor 3 1 1 
causes transmission of the event data packet, which includes a destination address of 
remote computer 334, through communications interface 318, as indicated at step 416. 

10 Accordingly, the event data packet, albeit a copy thereof, is routed through WAN 325 to 
remote computer 334. 

Although it is desirable to have event monitor server 43 forward the event data 
from call center 10 to remote computer 334 as quickly as possible, other event monitor 
servers in various call centers likewise forward the event data collected from those data 

15 centers to the same computer 334 through WAN 325, resulting in a competition for use of 
the limited bandwidth of WAN 325. Thus, during peak call times, data traffic from 
different event monitor servers may exhaust the capacity of WAN 325, thereby incurring 
a significant transmission latency. 

To effectively handle such a latency, event monitor server 43 transmits the event 

20 data in accordance with the aforementioned data throttling scheme. To that end, the 
length of a data throttling time window and a minimum latency value are specified in 
configuration file 315. Based on such information in file 315, processor 3 1 1 defines a 
series of data throttling time windows of the specified length. During a data throttling 
time window, processor 103 measures the time difference, i.e., latency, between 

25 transmitting an event data packet and receiving an acknowledgment of receipt of the 
packet from remote computer 334, as indicated at step 419. Processor 31 1 at step 422 
determines whether the measured time difference exceeds the minimum latency value 
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specified in file 315. If it does not, processor 3 1 1 at step 423 sets Flag to zero, and the 
subject routine returns to step 403 previously described. Otherwise, if it does, processor 
31 1 at step 424 sets FLAG to one, and the subject routine then returns to step 403. 
Referring back to step 414, if it is determined there that Flag = 1, processor 31 1 proceeds 
5 to step 425 where it places the event data packet to be transmitted in a first-in-first-out 
(FIFO) queue in memory 313 to slow down the rate at which the event data is forwarded 
to remote computer 334. The event data packet in the FIFO queue then enters a wait state 
as indicated at step 428 before its transmission at step 416. The waiting period for a 
packet in the FIFO queue may vary with the amount of latency measured. To that end, 

10 configuration file 315 may contain a second table for processor 31 1 to translate each 

latency amount to the corresponding waiting period. Thus, by looking up such a second 
table to prescribe appropriate waiting periods, processor 3 1 1 can effectively control the 
transmission data rate in response to different latency amounts. 

In addition, if for any reason the connection between event monitor server 43 and 

15 remote computer 334 is lost, processor 3 1 1 caches all event data to be transmitted in 
memory 313 until the connection is reestablished. At such time, processor 3 1 1 resumes 
transmission of the event data from memory 313 to computer 334. A loss of the 
connection may be determined when processor 31 1 receives no signal from WAN 325, 
e.g., acknowledgment of receipt of any transmitted event data packet, within a 

20 predetermined time limit. Such a time limit may also be specified in configuration file 
315. 

It should be pointed out at this juncture that the use of configuration file 315 here 
is advantageous in that after the functions for event monitor server 43 are established, 
they can be flexibly implemented based on the parameters specified in file 315. For 
25 example, for the data compression function, when the need arises one can easily modify 
the terms and the corresponding representations in the translation table in file 315. 
Similarly, for the data throttling function, one can easily change the specifications of the 
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data throttling time window size and/or the minimum latency value in file 315 to affect 
the data throttling scheme. 

In addition, in accordance with an aspect of the invention, processor 3 1 1 may be 
programmed to perform a data filtering function, whereby selected event records are 
5 filtered out without further processing. For example, event records concerning selected 
carriers may be filtered out by processor 31 1 examining CARRIER_ID field 237 of each 
record. If field 237 of the record has one of the values corresponding to the selected 
carriers, processor 3 1 1 may disregard the record. The filter parameters, e.g., the identities 
of the fields and particular field values, based on which processor 3 1 1 screens out 

10 unwanted event records may be specified in configuration file 315 to facilitate changes in 
the parameters from time to time. 

In accordance with another aspect of the invention, to more effectively utilize the 
limited bandwidth of WAN 325, priority of event records for transmission may be 
established. For example, the priority may be based on the particular event class and type 

15 of the records which are identified by the particular values in EVENT_CLASS_ID field 
21 1 and EVENT_TYPEJD field 247 of the records, respectively. To that end, 
combinations of EVENT_CLASS_ID and EVENTTYPEJD values corresponding to 
different event classes and types which are accorded priority are specified in 
configuration file 315. For each combination, a priority value, e.g., a high or low priority 

20 value, can also be specified in file 315. In accordance with such a priority specification, 
processor 3 1 1 arranges the order of event records to be transmitted. Each event record is 
assumed to be of normal priority unless the values in fields 2 1 1 and 247 of the record 
match one of the combinations specified in file 315. In that case, processor 31 1 reads the 
priority value associated with the matched combination to determine whether the record 

25 is accorded a high or low priority status. In this illustrative embodiment, processor 3 1 1 
causes a high priority event record to be transmitted ahead of normal and low priority 
event records, and normal priority event records ahead of low priority event records. 
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In an alternative embodiment, the priority is specified in file 315 in terms of a weight 
value W relative to a predetermined weight for medium priority. By way of example, 
let's say the predetermined weight for medium priority is 10. In accordance with this 
priority scheme, processor 3 1 1 causes transmission of event records having a W priority 
5 weight ahead of medium priority event records in the proportion of W out of (W + 10) 
times. For example, relatively high priority event records having W = 20 are transmitted 
ahead of medium priority event records 20 out of 30 times, i.e., two out of three times. 
On the other hand, relatively low priority event records having, e.g., W = 2 are 
transmitted ahead of medium priority event records 2 out of 12 times, i.e., one out of six 
10 times. 

A daemon process runs on remote computer 334 and is used to receive event data 
packet from various call centers including center 10 through WAN 325. As is 
conventional, the daemon process is an agent program which continuously operates on 
computer 334 as a background process and performs system- wide functions. In this 

15 instance, these functions include de-packetizing the received packets to extract the event 
data contents therein. The daemon process also performs decompression of the event 
data according to a translation table inverse to the above-described translation table in 
configuration file 315. That is, it translates any representations of the terms used in the 
event record back to the original terms. It further inserts data from the recovered event 

20 records into a database, e.g., the aforementioned BASIC EVENT table, which may be an 
Oracle-type database. However, for effective analysis of the event data, other summary 
tables described below are formed. Queries may be formed against the database and 
summary tables to obtain useful information therefrom. 

In accordance with another aspect of the invention, remote computer 334 is 

25 programmed to perform an auto-generation process for generating in real time event 
records, referred to as "child records", based on selected ones of the recovered event 
records, referred to as "parent records". As data from the recovered event records is 
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being inserted in the aforementioned database, the auto-generation process identifies from 
the records any parent records which satisfy certain criteria, and generates the 
corresponding child records. The child records, thus generated, would be treated 
similarly to any other event record. 
5 For example, one such child record generated by the auto-generation process in 

accordance with the invention is a "long distance connection" event record, which 
captures an event where a user is connected to a destination number through a call center, 
e.g., call center 10, via a long distance connection. Thus, such a long distance connection 
record may be derived from those event records which indicate that an outbound call, or a 

10 conference call was made through the call center, provided that such a call involves a 
long distance connection. To that end, instructed by a routine of the auto-generation 
process, computer 334 examines E VENT_CL AS S_ID field 21 1 and EVENT JTYPEJD 
field 247 of the event records being inserted in the database. Computer 334 identifies 
those event records having selected EVENT_CLASS_ID and EVENT_TYPE_ID values 

15 indicating that an outbound call or a conference call was made through a call center, as 
shown at step 503 in Fig. 5. In this instance, the identified records, which are potential 
parent records, each bear an EVENT_CLASS_ID value 20, and an EVENT_TYPE_ID 
value 14, 20 or 22. Computer 334 at step 506 examines a DIALED_DIGITS field (not 
shown) in each identified record which contains the destination number connected 

20 through the call center. Computer 334 at step 509 determines whether the destination 
number is a valid phone number. In a well known manner, in making such a 
determination, computer 334 checks whether the destination number consists of only 
numerals, and is in compliance with the standard telephone numbering plan. If it is 
determined that the destination number is not a valid phone number, the subject routine 

25 comes to an end. Otherwise, the routine proceeds to step 512 where computer 334 looks 
up the value in SITE_ID field 233 of the identified record which specifies the call center 
involved. 
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It should be pointed out at this juncture that an LCAJDATA table is maintained in 
a memory (not shown) of computer 334. This table provides number plan areas (NPAs), 
also known as "area codes", of local calling areas for each call center specified by its site 
ID. Thus, any connection by the call center to a destination number having its NPA 
5 matching one of the local calling area NPAs associated with the call center is considered 
a local connection. 

Continuing the above example, computer 334 at step 515 looks up in the 
LCA_DATA table the local calling area NPAs corresponding to the site ID value in the 
identified record. Computer 334 at step 5 1 8 determines whether the NPA of the 

10 destination number identified at step 506 matches one of the local calling area NPAs just 
looked up. If it is determined that the NPA of the destination number matches one of the 
local calling area NPAs, the subject routine comes to an end as the connection by the call 
center to the destination number is considered a local connection. Otherwise, if it is 
determined that the connection is a long distance connection, computer 334 generates a 

15 long distance connection event record based on the identified record, as indicated at step 
521. Specifically, in this example computer 334 duplicates the identified record, and 
changes the EVENT__TYPE_ID value of the duplicate record to "24", with 
EVENT_CLASS JD value unchanged as, in this instance, the EVENT_CLASS_ID = 20 
and EVENT_TYPE_ID = 24 jointly identify the newly-generated record as a long 

20 distance connection event record. 

The routine of Fig. 5 similarly applies to auto-generation of another type of child 
record, namely, a "national search" event record. The auto-generation of a national 
search event record is different from that of Fig. 5 partly because of different types of 
parent record from which the national search event record depends. Thus, in auto- 

25 generating the national search event record, computer 334 identifies at step 503 those 

parent records representing a detailed listing search event by a call center, instead. If the 
destination number in any such parent record resulting from the search event corresponds 
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to a long distance number, which may be determined by going through steps 506, 509, 
512, 515 and 518 previously described, computer 334 determines that the search event in 
question also includes a national search event. Computer 334 then similarly generates a 
national search event record based on the parent record. 
5 In addition, the routine of Fig. 5 may be readily modified to identify those 

outbound calls or conference calls which were connected by a call center to a special 
service, thereby auto-generating a "special service" event record. Examples of special 
services include services providing horoscope, weather, traffic, local event and movie 
information. To that end, a SPECIAL_CONNECTION table is also maintained in the 

10 memory of computer 334. This table lists all known phone numbers used by call centers 
for the special services. For example, after going through steps 503, 506 and 509, 
computer 334 in this instance checks the destination number in an outbound call event 
record or a conference call event record against the listed phone numbers in the 
SPECIALCONNECTION table. If the destination number matches one of the listed 

15 phone numbers in the table, say, the horoscope service number, computer 334 similarly 
generates a horoscope service event record based on the corresponding outbound call 
event record or conference call event record. 

As mentioned before, summary tables are formed to summarize event data to 
facilitate analysis of the data. In this illustrative embodiment, one such summary table is 

20 referred to as a "SUM_EVENTS" table. In accordance with the invention, a 

SUM_EVENTS table tracks the statistics of the events of a given class and type which 
occur in a specified period having a predetermined interval, e.g., a 15 minute interval, and 
which may also originate from specified call centers, carriers and/or markets. Fig. 6 
illustrates the format of one such SUMJ2VENTS table, denoted 600. As shown in Fig. 

25 6, table 600 includes SUMJEVENTS_ID field 603 containing an assigned value for 
identifying table 600. In this instance, table 600 concerns those event records having 
selected EVENT_CLASS_ID values specified in field 605, selected EVENT_TYPE_ID 
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values specified in field 607, selected SITE_ID values as specified in field 613, selected 
CARRIER_ID values as specified in field 615, and selected MARKETJD values as 
specified in field 617. In addition, the event records being considered are required to 
have an event start time, which is provided in field 241 of the records, within the period 
5 interval (e.g., 15 minutes) specified in field 61 1 from the period start time specified in 
field 609 (which is in date/time format). Event records meeting the above criteria are 
continually added to table 600 and then summarized. For example, 
ENH ANCEDE VENT 1 COUNT field 619 tallies the number of the event records in 
question and thus the specified events represented thereby. Other summarization data 

10 includes, e.g., statistics concerning the total duration, median duration and longest 
duration of the specified events. 

Another summary table, referred to as a "SUM_CALLS" table, may be formed to 
track statistics concerning selected information assistance calls handled over a specified 
period. For example, the selected information assistance calls each may have at least one 

15 event of a given class and type occurring during the call, and may also originate from 
specified call centers, carriers and/or markets. As such, the format of a SUM_CALLS 
table is similar to that of a SUM_EVENTS table described above. However, the 
SUM_CALLS table differs from a SUM_EVENTS table in that summarization data in 
the former is generated on a call basis while summarization data in the latter is generated 

20 on an event basis. As discussed before, an information assistance call can include 

multiple events. Thus, for example, three "conference call" events defined by being of 
particular event class and event type causes the record count in a SUM_EVENTS table to 
be incremented by three, regardless of whether two or all of them occur in the same 
information assistance call. However, in that case, the corresponding call count of an 

25 analogous SUM_CALLS table would be incremented by only one. Thus, in generating 
the summarization data in a SUM_CALLS table, only those event records meeting the 
criteria specified in the table and also having different CDR_CALL_SEQJSfMBR 
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(CCSN) values are considered. As mentioned before, the CCSN value in field 213 of an 
event record identifies the information assistance call in which the event represented by 
the record occurs, and event records attributed to the same call have the same CCSN 
value. Thus, in generating the summarization data in a SUM_CALLS table, a list is also 
5 compiled to keep track of CCSN values associated with the event records which have 
been considered. Any event record which bears one of the CCSN values in the list but 
otherwise satisfies all of the specified criteria in the table would be ignored as the 
corresponding call has been taken into account. 

Yet another summary table, referred to as a "SUM_FREQCOUNT" table, may be 

10 formed to track the number of calls in which none or some "enhanced" events occurred. 
In this illustrative embodiment, an enhanced event is a selected event of particular 
interest. For example, the aforementioned STARBACK events, long distance connection 
events and national search events are designated enhanced events in this instance. Fig. 7 
illustrates a portion of a SUM_FREQCOUNT table (denoted 700) for summarizing 

15 enhanced event data satisfying the specified criteria. In table 700, VAL_0 field 703 
registers the number of information assistance calls accrued during the specified time 
period, each of which has no enhanced event satisfying the specified criteria therein; 
VAL_1 field 705 registers the number of information assistance calls accrued during the 
specified time period, each of which has only one enhanced event satisfying the specified 

20 criteria therein; VAL_2 field 707 registers the number of information assistance calls 
accrued during the specified time period, each of which has two enhanced events 
satisfying the specified criteria therein; VAL_3 field 709 registers the number of 
information assistance calls accrued during the specified time period, each of which has 
three enhanced events satisfying the specified criteria therein; and VAL_4+ field 71 1 

25 registers the number of information assistance calls accrued during the specified time 
period, each of which has four or more enhanced events satisfying the specified criteria 
therein. 
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In order to fully appreciate the methodology for developing the summarization 
data portion of table 700, an accessory table used in such a methodology will now be 
described. Fig. 8 illustrates such an accessory table (denoted 800), which tabulates the 
number of enhanced events occurring in each qualified information assistance call 
5 identified by its CCSN. To that end, table 800 accommodates pairs of CCSN and 

NUM_ENHANCED_EVENTS (NEE) values in rows. In each row, a CCSN identifies a 
qualified assistance information call, and the associated NEE value represents the number 
of enhanced events occurring in the qualified information assistance call. 

Fig. 9 illustrates routine 900 for generating the summarization data portion of 

10 table 700 and developing table 800 in the process. Instructed by routine 900, computer 
334 selects from all event records those satisfying the specified criteria described above. 
For each selected record, computer 334 further determines whether the selected record is 
associated with a "existing" or "new" information assistance call, and whether the 
recorded event is an enhanced event or not. An information assistance call is said to be 

15 new when computer 334 first encounters the CCSN value in the selected record 

identifying such a call. Specifically, for each selected record, computer 334 at step 903 
determines whether the CCSN value in the selected record matches any CCSN value in 
CCSN column 803 in accessory table 800. If there is no match, the information 
assistance call associated with the selected record is considered new. In that case, 

20 computer 334 at step 906 adds the CCSN value in the selected record to CCSN column 
803. Routine 900 then proceeds to step 909 where computer 334 determines whether the 

event represented by the selected record is an enhanced event. In such a determination, 

j 

computer 334 checks the pair of values of EVENT_CL AS S_ID field 21 1 and 
EVENT TYPE ID field 247 of the selected record against a pre-set list of 
25 EVENT_CLASS_ID and EVENT_TYPE_ID value pairs, which identify predetermined 
enhanced events. Only if the value pair of the selected event record matches one of the 
value pairs in the pre-set list, should the event represented by the selected record be 
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designated an enhanced event. In that case, computer 334 enters a count "1" in NEE 
column 805 of accessory table 800 next to the CCSN value just added, as indicated at 
step 912. In addition, computer 334 at step 915 increments the value of VAL_1 field 703 
in table 700 by one as a new call with an enhanced event occurrence has been identified. 
5 It should be noted that VAL_0, VALJ , VAL_2, VAL_3 and VAL_4+ fields 703, 705, 
707, 709 and 71 1 of table 700 are initially set to zero. 

Returning to step 909, if it is determined that the event represented by the selected 
record is not an enhanced event, computer 334 at step 918 increments the value of 
VAL_0 field in table 700 by one as a new call with no enhanced event occurrence has 

10 been identified. 

Returning to step 903, if the CSSN value in the selected record is not new, i.e., the 
CSSN value in question matches one of the CSSN values in column 803, computer 334 at 
step 921 determines whether the event represented by the selected record is an enhanced 
event. If it is not, computer 334 at step 922 ignores the selected record as the latter has no 

1 5 effect on field 703, 705, 707, 709 or 7 1 1 . Otherwise, if it is determined that the subject 
event is an enhanced event, computer may need to modify the summarization data in one 
or more of fields 703, 705, 707, 709 and 71 1 to reflect an increase in the number of 
enhanced events occurring in a call which has been taken into account. To that end, 
computer 334 at step 924 increments the NEE value in table 800 associated with the 

20 CSSN value in question by one, resulting in a new NEE value = K, where K represents an 
integer greater than zero. Computer 334 determines at step 927 whether 0 < K < 4. If 
that is the case, computer 334 at step 931 increments the value of VAL_K field of table 
700 by one, and at step 934 decrements the value of VAL_(K-1) field by one. 
Otherwise, if K ^ 4, computer 334 determines whether K = 4, as indicated at step 937. If 

25 that is the case, computer 334 at step 941 increments the value of VAL__4+ field 71 1 of 
table 700 by one, and at step 943 decrements the value of VAL_3 field 709 by one. 
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Otherwise, if K > 4, computer 334 at step 947 ignores the effect of the selected record as 
far as table 700 is concerned. 

The foregoing merely illustrates the principles of the invention. It will thus be 
appreciated that those skilled in the art will be able to devise numerous other 
5 arrangements which embody the principles of the invention and are thus within its spirit 
and scope. 

For example, in the disclosed embodiment, remote computer 334 is used to 
receive and process event data from various call centers. It will be appreciated that 
multiple remote computers similar to computer 334 may be geographically distributed to 

10 share the data load especially when the volumes of event data transmitted from the call 
centers are large. In that case, each remote computer sends, to the event monitor server in 
each call center, a feedback signal indicating its current load, thereby properly directing 
data traffic to those remote computers having a lesser load. 

In addition, in the disclosed embodiment, remote computer 334 performs the 

15 function of analyzing and compiling statistics based on event data. In an alternative 
embodiment, such a function is distributed among call centers. For example, the event 
monitor servers in the call centers may respectively perform such a function on the event 
data generated from the centers, and the resulting statistical data is then transmitted from 
the respective centers to computer 334. 

20 Finally, call center 10 is disclosed herein in a form in which various functions are 

performed by discrete functional blocks. However, any one or more of these functions 
could equally well be embodied in an arrangement in which the functions of any one or 
more of those blocks or indeed, all of the functions thereof, are realized, for example, by 
one or more appropriately programmed processors. 
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